Email messages can generally be separated into two broad categories:
Although it is possible to create an email message combining elements which are both non-MIME and MIME, this is not recommended. PowerTCP Mail for .NET constructs only MIME messages from its object model.
A non-MIME message refers to any message that is created in the original format defined in RFC822. These messages are generally made up of simple text and Uuencoded or Yencoded attachments. Non-MIME messages can be fully decoded by PowerTCP Mail for .NET.
MIME (Multipurpose Internet Mail Extensions) was defined to expand upon the original RFC822 message structure to provide a means for creating complex-multipart messages. MIME messages are usually recognizable by the "MIME-VERSION : 1.0" header line and the MIME-boundary separating the parts of the message.
Almost all email readers today are MIME compatible, so it is almost always desirable to create MIME messages. Create a non-MIME messages only if it is likely that the receiving mail reader is unable to read MIME.
The text-only format described by RFC 822 is extremely limiting. MIME allows an email message to contain data other than text, and still be backwardly-compatible with non-MIME compatible mail servers. When MIME was implemented, it caused some changes to the original message structure specified in RFC 822. Additional MIME-specific header fields were required to specify the MIME content. The structuring of the message body was changed to allow multiple types of files. Also, encoding rules were specified for non-ASCII attachments. Implementing MIME in this way allowed mail transfer agents to remain the same. Only the sending and receiving clients needed to be changed, in order to handle MIME attachments.
The message header fields added to the RFC 822 mail structure are:
Of these headers, the two most pertinent to this discussion are the Content-Transfer-Encoding header field and the Content-Type header field.
Content-Type specifies the nature of the message body (the type of file). RFC 1521 defined seven types (which are still under revision):
This field dictates the content of the part so the client may handle it appropriately. Each type has a subtype which defines the specific format for the data. These fields demonstrate an ASCII text message sent with a MIME compliant user agent:
< RFC 822 header fields omitted > Content-Transfer-Encoding: Quoted-Printable Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 < message content (ASCII text omitted) >
This header indicates that MIME version 1.0 and Quoted-Printable encoding (more on this later) were used. The Content-Type type is "text" and the subtype is "plain," meaning that it is simple ASCII without other formatting applied.
As another example, these MIME header fields demonstrate a message containing only a single image:
< RFC 822 header fields omitted > MIME-Version: 1.0 Content-Type: image/gif; name="Dart.GIF" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dart.GIF" < encoded message omitted >
Again the MIME-Version is 1.0, but the encoding used was Base64. The Content-Type is "image" and the subtype is "gif," indicating to the receiving user agent that the file "Dart.GIF" is indeed a "gif" type of image.
The Content-Transfer-Encoding header field indicates the type of MIME-encoding used, so the receiving client can properly decode it using the same algorithm. Most file formats are 8-bit files in their natural state, but the SMTP protocol restricts messages to 7-bits. Encoding creates a 7-bit file from an 8-bit file, allowing compatibility with all SMTP agents.
RFC 2045 defines the use of two encoding algorithms, Quoted-Printable and Base64. There is no definable relationship between these algorithms and the Content-Type header field. In other words, the same file type is not always encoded with the same algorithm.
An 8-bit character has 256 possible combinations (2^8). Of these, 128 (2^7) are printable ASCII characters (7-bit characters). These 7-bit characters are not a problem for transfer. To handle characters 128-256 (the characters represented by 8-bits), hexadecimal values are used. For example, a character with the value of 200 is encoded as "=C8".
Quoted-Printable encoded data is assumed to be line oriented. In fact, since ASCII characters are kept in their original form, often a file encoded with Quoted-Printable is highly readable. Using this encoding, lines are transmitted in lengths no longer than 76 characters. Here is an example:
<!doctype HTML public "-//W3C//DTD HTML 4.0 Frameset//EN"> <html> <!--(=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D)--> <!--(Document created with RoboEditor. )=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--> <!--(=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D)--> <head> <title>Tutorial</title>
This document is apparently a portion of an HTML page, as some tags made up of ASCII characters have been preserved. There are quite a few encoded characters as well, clearly identifiable by the "=" preceding them.
Base64 encoding is entirely different from Quoted-Printable encoding. There is no attempt for the encoded data to be human-readable. Also, this form of encoding results in the encoded data being 33% larger than the original data. In base64, groups of 24-bits are separated. Natively, the data is represent in three "8-bit" segments. This data is encoded as four "6-bit" segments due to the 7-bit constraint. Here is an example:
pcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAAnRsAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAJBBYAIjgAAIBXAACAVwAAnRcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAACABAAAAAAAAIAEAACAB AAAAAAAAIAEAAAAAAAAgAQAAAAAAACABAAAAAAAAIAEAABQAAAAAAAAAAAAAADQBAAAAAAAAeAkA AAAAAAB4CQAAAAAAAHgJAAAAAAAAeAkAAAwAAACECQAAJAAAADQBAAAAAAAAA1UAAGgBAAC0CQAA AAAAALQJAAAAAAAAtAkAAAAAAAC0CQAAAAAAALQJAAAAAAAAtAkAAAAAAAC0CQAAAAAAALQJAAAA AAAAglQAAAIAAACEVAAAAAAAAIRUAAAAAAAAhFQAAAAAAACEVAAAAAAAAIRUAAAAAAAAhFQAACQA AABrVgAAIAIAAItYAAB8AAAAqFQAABUAAAAAAAAAAAAAAAAAAAAAAAAAIAEAAAAAAAC0CQAAAAAA
As expected, the structure of the data is completely changed making the result unreadable.
MIME allows the creation of messages with multiple parts. Possible parts include text parts, HTML parts and attachments. Parts can also be "multipart," allowing for nested parts. For example, if a file is attached to a message, the Content-Type in the main header becomes multipart, indicating that there are more parts than the message text. These parts are enumerated after the main header, separated by an automatically generated divider. Each of these parts may be encoded with a different encoding algorithm. The following demonstrates a message comprised of text, a gif file and a word doc.
The header is at the top of the message.
Return-Path: <test@test.com>
Received: from YOURCOMPUTER ([192.168.0.00]) by yourserver.com
(Post.Office MTA v3.5 release 215 ID# 0-54045U100L2S100V35)
with ESMTP id com for <test@email.com>;
Fri, 2 Feb 2001 11:09:42 -0500
To: test@email.com
From: test@test.com
Subject: multipart email
MIME-Version: 1.0
Content-Type: multipart/mixed; Boundary="--PTCP_00011cb405020407d1"
Message-ID: <00011cb505020507d1@[192.168.0.71]>
Date: Fri, 02 Feb 2001 11:10:35 -0500
All fields from the original RFC 822 specification are present, but for this example, let's focus on the Content-Type. The type is described as multipart/mixed, which indicates there are several independent parts after the main header. The Boundary separates these parts; in this case with the character string, "--PTCP_00011cb405020407d1."
----PTCP_00011cb405020407d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable This message is a multipart MIME test. ----PTCP_00011cb405020407d1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dart.GIF" Content-Type: application/octet-stream; name="Dart.GIF" R0lGODlhbwAmAPf/AP///xAQECEhISkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4SE hIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v7/f39+fe3tbGxrWcnGMxMVIA < other Base64 encoding omitted > ----PTCP_00011cb405020407d1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dart site report.doc" Content-Type: application/msword; name="dart site report.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAKAAAAhwQAAAAAAAAA EAAAiQQAAAEAAAD+////AAAAAH0EAAB+BAAAfwQAAIAEAACBBAAAggQAAIMEAACEBAAAhQQAAIYE < other Base64 coding omitted > ----PTCP_00011cb405020407d1--
The three MIME parts are clearly exhibited, each delimited by the aforementioned Boundary string. The first part is the plain text message. It is encoded with Quoted-Printable, but is comprised of ASCII characters and is therefore intact: "This message is a multipart MIME test." The second part is the image "Dart.GIF." It is encoded with unreadable base64. The third part is the Microsoft Word document, "dart site report.doc." The message ends with a final Boundary string.